Simplicity

I've spent the past few days away from the city, down at the coast, in a house ovelooking the Tasman Sea, walking along quiet beaches, and at night, gazing up at the rich star-fields of the southern Milky Way. The stars shine with a special brilliance in the clear winter air, far from the street lights. It's made me think of the simplicity that underlies everything in Nature, no matter how apparently complex on the surface. It occurred to me again to apply this approach to solving the Riddle.

I've said on a number of occasions that I think the solution will be simple, indeed obvious when seen in hindsight. This is the only solution that is consistent with +ORC's Zen philosophy. I don't think a complex solution is likely.

I'd like to explore the significance of this idea, as I think it's the only way we're going to find the hidden URL.

First I'll take a step back to justify this, by thinking about how the Riddle might have been constructed. If I were to devise a riddle that I intended people to solve, I would not hide the solution so deeply in complexity that no-one would ever solve it except by accident. I cannot see +ORC using a different approach, as I think he is, fundamentally, a man of reason. If my thinking is substantially wrong here, I can safely say that nobody will ever solve the Riddle. Since my aim is to solve it, I can only proceed in what I think is the most reasonable and likely manner. This inevitably means assuming that (a) +ORC is reasonable, and (b) the solution is therefore straightforward, even if non-obvious. I think that it will involve some element of subtlety, too.

This approach to the Riddle also offers a philosophical basis for all sorts of other analyses, especially cracking software protection schemes. Hence I think it is an approach +ORC would be likely to take.

So what do we start with? A URL consisting of four octet groups and a suffix in the form of a directory. Second, we have the Riddle, which consists of five lines, the first four of which include a clearly stated number, and a series of other elements, which may mean numbers or may indicate a way of using the explicit numbers, or may signify nothing - noise.

Now the URL octets are number groups, there are four of them, and there are four lines in the Riddle that include explicit numbers. The simplest solution is to apply the number from each consecutive line to each consecutive URL octet. That is, we apply "6 bars" to 131, "5 bars" to 92, "4 bars" to 15, and "0 bars" to 128.

There are several ways to do this, which I have mentioned earlier in these pages, and which I will discuss below. Limiting our attention to the explicit numbers in the Riddle and applying these (in some way) sequentially to the number groupings in the URL seems to me far and away the simplest thing to do, and suggests at least part of the response to the instruction "correct this link" that accompanies the Riddle.

The next step is to look at the fifth line of the Riddle, the one that contains no number, and seek a way to apply it to the suffix "+ORC". This "application" may indeed be a null application - ie do nothing. But I think we need to do something with it. So there are two activities emerging from this analysis. The first is the numerical application of one sequence of numbers to another sequence of numbers. The second activity is the modification of one ASCII string with elements of another.

Let's look at the numbers first.

We have six bars, five bars, four bars, and zero bars. These can mean the decimal numbers 6, 5, 4, and 0, or they can mean six binary "ones", etc. This, taken in its simplest form, means the decimal numbers 63, 31, 15, and 0. There are no other obvious, simple possibilities that I can see.

How do we "apply" them to the URL? I've said before that we can use any of the arithmetic operators or any of the logical operators. My immediate reaction is to expect that we should use only one operator for every case. This might be wrong, and it might be that one of the subsidiary terms in each line of the Riddle is the clue to what operator to use. But since the subsidiary terms that are present in the lines are far from obvious, I think the demand for a simple solution requires us to choose a single operation. [This is a weak point in the analysis so far, and one to which we should return in case of failure.]

Looking at the available operators, we have +, -, /, x, AND, OR, XOR (and a few other unlikely ones such as NOT, NOR, NAND). I've also said before that multiplication and division are unlikely as we want integer answers within the bounds (1, 254). I can also see no justification for XOR or any of the "minor" logical operators, as they are not intuitive operations. This leaves us with Plus, Minus, AND and OR. I favour Plus and AND for intuitive or linguistic reasons. Much the simplest is of course, Plus.

Depending on what we choose "6 bars" to mean, the Plus operator gives us the octet sequence 137.97.19.128 (using 6,5,4,0) or 194.123.30.128 (using 63,31,15,0). The AND operator gives us 2.4.4.0 or 3.28.15.0 . Minus gives us 125.87.11.128 or 68.61.0.128 . Finally, OR gives us 135.93.15.128 or 191.95.15.128 . Now I think it unwise just to assume that "0" figures or first-octet groups below 128 are ruled out. By choosing this simple approach, there are only a limited number of URL number sequences to check, and seeing whether the IP address is alive or not won't take long. There's no need here for a shortlist.

The final problem is to look at the ASCII strings and see what's implied. We should also, I think, keep in the back of our minds that the "+ORC" suffix may also indicate (perhaps in part) a port number. It might also be prudent to look at part of the "128" final octet and ask whether that might not also be split into an octet and a port number. For instance, we might interpret the URL element ".128/+ORC" as ".12:80/RC" ie port 80 and directory RC . But that's for later, if we fail here, as it is less transparent, obvious and simple.

So what can we find that is alive and responds to some form of IP Address lookup or Ping or Port Sniff?

Well, the good news is there is some very useful software tools out there that let us look at the URLs. I'm writing up reviews of the software that I've looked at for this purpose. The page will be linked here when I finish it, and also on the main entry page (so come back here and see if I have). The two main programs I have used are Port Scanner and NetScanTools. Both are shareware. There are also some other very good freeware tools available, namely WS-Ping, NetLab and NS-Batch. As +ORC says, the Net is a source of great bounty.

What do we find? Alas, not a lot. None of the URL sequences generated here showed any sign of life. No answers to Pings, no domain names, no active ports.

What did I do next? I looked at modifying the final URL octet to read ".12:80" . No result.

If there is no server active on the IP address, there is no sense worrying about what directory to look in.

What can we conclude? There are several possibilities:

• There is a correct "simple" solution that I've overlooked.
• There is another key clue that we don't yet have (eg the Shonsu saga).
• The URL has in fact died and is no longer findable.
• +ORC has set a Riddle that does not have a simple solution, perhaps because he does not want us to find the page.

Your philosophical preferences will determine which of the above you think is the most likely.

Being an optimist, I prefer the first or second. But I'm not confident that I will break the Riddle. Perhaps, like some software protection schemes, the encryption implicit in the Riddle is so strong that it is not in practice crackable.

Where to from here?

I don't know. I'm feeling philosophical but not encouraged. I can only think that the Riddle means something entirely different than I've been searching for. But what?

My regards to all the +ORC seekers who are following this odyssey. And, indeed to +ORC himself, for setting such an engaging riddle.